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Abstract — Software development projects are subject to risks like any other project. Software development is subject to 
unique risks which can be mitigated through effective risk management techniques. Risks are unavoidable and must be 
managed. Successfully managing risks assists developers in completing the project on time and on budget. Strategies 
selected to manage risk may result in a better product than originally anticipated. Identifying, analyzing, tracking, and 
managing software risk aids crucial decision making including release readiness. Software project suffers from many 
problems like high computational cost, higher delay time in designing the projects, not meeting the actual need of the user, 
and many systems are being unutilized. These problems are solved using the software risk management which helps the 
software developer to identify, analyze, and accordingly deal with software risks items. 

Software risk management is also an attempt to define and formulate the risk oriented connection of success into a definite 
set of methods and techniques. Global Software development is learning and individuals escalated action. Individuals in such 
gatherings must work together, convey, and coordinate their work, which makes learning management a need. Point of the 
fact, little and stable associations where workers are inside an arm 's compass of one another can most likely make without 
information management. In any case, for associations that are huge and appropriated, whose environment is consistently 
changing, or have a high turnover, dealing with their information stakes are basic for survival. 

This Paper focuses on a pilot survey carried out at small software firms and results of employees are recorded and analyzed 
with help of IBM SPSS. 

Keywords — Risk Management, management & computational cost. 

I. Introduction 

Project managers observe and aide the work of planners, designers and analyzes of software while now and again taking part 
in these exercises themselves. Where developer concentrates on code, construction modeling and execution, managers keep 
tabs on elevated amount concerns: the course of the project, allotment of assets, the list of capabilities, and the client 
experience. Supervisors work to synchronously fulfill stipulations imposed by clients, engineers, analyzers, maintainers and 
management. 

Creating value for different customer segments is essential to the business of a company. Thus, software product 
development companies' ability to implement the most valuable requirements in their products has been seen as critical. The 
literature offers requirements prioritization methods for selecting requirements, but their suitability for solving practical 
challenges is not clear. The state of the practice in long-term product planning and requirements prioritization, and the 
practical challenges involved is not thoroughly analyzed. Therefore, the connection between the selection of product features 
and customer value creation is also an area that needs more investigation. 

For a software development company, product development is an investment that should provide maximal added. Providing 
value for different customer segments by means of the product is a lifeline for the sales of the product, and via that, to the 
business of the company. Understanding what customer value means, and how to create value for a large number of 
customers, however, is not trivial in practice. From the product development viewpoint this means that a company needs the 
ability to implement the most valuable requirements in a software product in each product release. Especially in the software 
product business, the role of the successful selection of the feature enhancements (i.e., requirements) for product releases is 
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recognized as extremely important. Market-driven requirements engineering (RE), however, seems to entail special 
challenges, for example in requirements prioritization and release planning. 

The ultimate sponsors of the project expect that the project’s end result will add more value for them than they are paying the 
project team to create it. On a high level, this means that companies expect their product development organization to add 
more value to them than they invest in product development. The purpose of requirements engineering activities is to add 
business value that is accounted for in terms of software product’s return on investment The need to make business -based 
product development decisions means that a company needs the ability to connect business management and software 
development .Only by integrating upstream (that is, long-term product planning) and downstream (that is, software 
development) processes, can value-based decisions concerning the future features of the products be made Long-term 
product planning is one approach that companies have used to bridge the gap between business planning and product 
development. Roadmapping is widely used as a technique in the manufacturing. The application of the roadmapping 
approach in the software engineering field is rather new and has not been investigated that much. Additionally, the practical 
implications of long-term product planning in software product companies in terms of the state of practice or of good 
practices are not systematically studied. 

Some rationales for the challenges involved in requirements prioritization have been reported in the earlier studies. It is 
widely accepted that requirements prioritization involves complex decision-making. In order to prioritize requirements 
successfully, domain knowledge and estimation skills are required. In addition, requirements depend on each other and 
priorities are always relative. An important requirement in one release or to a certain customer may not be as important in the 
next release or to another customer. Political- and people- related issues are discussed, too For companies producing 
packaged software, the long-term planning and prioritization of requirements are even more challenging than for companies 
operating in project business. According to, the key differences between characteristics of packaged (market -driven) and 
bespoke software development concern stake holding and schedule constraints. 

For requirements engineering this means that in the development of packaged software the future requirements of the 
software cannot be negotiated with just one or a few customers. Instead, requirements engineering decisions such as the 
prioritization of potential requirements to be implemented must be made within the company and be linked to the business 
decisions of the company In addition, time-to-market is, for many software packages, a survival attribute). The normal 
response to schedule slip in these market-driven cases is to concentrate resources on meeting the most critical requirements 
with minimal delay. 

II. Literature Survey 

Customer value has many meanings in the literature, but two starting points dominate: value for the customer (customer 
perceived value or customer received value) and value for the firm (value of the customer, customer lifetime value) (Smith et 
al. 2007). In this thesis, the basic viewpoint on customer value is the former - customer’s perceived value. Many authors have 
acknowledged the difficulties involved in actually defining customer value (e.g. (Woodruff 1997)). These difficulties stem 
from the subjectivity and ambiguity of value, which is compounded by the fact that customer value is a dynamic concept that 
evolves over time (Naumann 1995). Furthermore, in different disciplines, the value concept is multifaceted and complicated 
by numerous interpretations, biases, and emphases (Huber et al. 2001; Sharma et al. 2008). Common for many definitions of 
customer value is that the concept is related to the trade-off between perceived benefits (what the customer receives) and 
sacrifices (what he or she gives up) to acquire and use a product according to the customer’s perception (Woodruff 1997). In 
order to truly analyse the customer value of the product, the benefits must be related to sacrifices a customer faces to get and 
use the product. Perceived benefits can be defined as “a customer’s perceived preference for, and evaluation of, those product 
attributes, attribute performances, and consequences arising from use that facilitates or blocs achieving the customer’s goal 
and purposes in use situations”(Woodruff 1997), not just product features. 

The narrowest definitions see “customer value” as the level of return on the product benefits for a customer’s payment in a 
purchase exchange (Normann et al. 1993). Wider definitions are not limited to monetary sacrifices, but assert that the 
judgment of value results from a trade-off between what the customer receives (e.g., quality, benefits, worth, utilities) and 
what he or she gives up to acquire and use a product (e.g., price, sacrifices) (Woodruff 1997). According to Smith and 
Colgate (2007) it is unclear whether customer value is a summative (benefits less sacrifices) or ratio (benefits divided by 
sacrifices). 

According to Slater (1997), firms exist to create value for others where it is neither efficient nor effective for buyers to 
attempt to satisfy their own needs. Many marketing strategists and industrial organization economists emphasize that creation 
of superior customer value is a key element for companies’ success (see e.g. (Porter 2004)). Customers do not look for 
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products or services per se; they look for solutions which they can use so that value is created for them (Gronroos 2007). 
Knowing where the value resides from the standpoint of the customer has become critical for suppliers (Ulaga et al. 2001) 
because greater levels of customer satisfaction lead to greater levels of customer loyalty, positive word-of-mouth, and a 
stronger competitive position (Bearden et al. 1983; Fornell 1992). Customer value is considered central to both competitive 
advantage and long-term success of business organizations (Khalifa 2004) 

Methods that combine aspects affecting priorities 


Method 

Short description 

Reference 

A HP 

(Analytical 

Hierarchy 

Process) 

All unique pairs of items are compared to determine which of 
the two is of higher priority, and to what extent. 

(Saaty 1980) 

Hierarchy 

AHP 

A modification of AHP in which only requirements on the same 
level of a hierarchy are compared with each other. 

(Saaty 1980) 

Cost- value 
approach 

AHP-based method in which all possible requirement pairs are 
compared according to their importance and implementation 
costs. The percentage share that a requirement has for total 
value and the total costs of all requirements are calculated for 
each requirement. (Cost-value approach is one instance of 
Hierarchy AHP) 

(Karlsson et al. 
1997b) 

Ordinal cost- 
value ap- 
proach 

Requirements are put into three groups according to their 
value to customers and into three groups according to their 
implementation costs. The results are presented in a cost- 
value scattered diagram. 

(Karlsson et al 
2005) 

Wiegers' 

method 

Each requirement is evaluated on a scale from 1 to 9 accord- 
ing to its value to the customer, the penalty if it is not imple- 
mented. implementation costs, and risks. Priority is calculated 
by dividing value + penalty by cost + risks. 

(Wiegers 1999) 

Impact 

validation 

The impact that each proposed requirement has on the 
achievement of the high-level goals of the project is evaluated 
on a defined scale. For each requirement an impact sum is 
calculated. The requirement having the greatest impact is 
seen as the most important and so on. 

(Gilb 2005) 

MDRPM 

(Market 

Driven 

Requirement 

Prioritization 

Model) 

AHP with a consistency check added to the normal procedure 

(Iqbal et al. 2010) 

Simulation- 

based Fuzzy 

Mult- 

attribute 

Decision 

Making 

Model takes the imprecise nature of requirements into account 
by modelling their attributes as fuzzy vanables 

1 Ejnioui et al. 
2012) 


Racheva et al. (2009) were, however, able to identify some characteristics to business value 

• Business value in practice tends to be qualitative 

• Business value tends to be subjective 

• The sources of business value drive requirements prioritization 

• Business value of the IT solution requires a degree of tmst 

• The business value and IT solution tends to be dependent on non- IT business processes 

Requirements prioritization started to gain interest in the requirements engineering research in the nineties, when general RE 
studies noted the challenges and importance of prioritization (Lubars et al. 1993). In the late nineties, authors also started to 
introduce methods for prioritizing requirements (e.g.(Beck 1999; Karlsson et al. 1997b; Wiegers 1999)), which continued in 
to the twenty-first century (e.g. (Berander et al. 2006a; Herrmann et al. 2008; Lauesen 2002; Leffingwell et al. 2003). The 
literature offers several methods for requirements prioritization. As requirements prioritization could be seen as a basic 
sorting problem of items, in theory any algorithms could be used to put a set of requirements in order. Comprehensive lists of 
methods and sorting algorithms proposed for requirements prioritization in the literature are presented e.g. in (Herrmann et 
al. 2008), (Kukreja et al. 2012) and (Racheva et al. 2010b). 

Different requirements prioritization methods introduced in the literature seem actually to be intended for slightly different 
purposes. These purposes can be e.g.: 
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• Sharing limited product development resources and solving conflicts between different stakeholders (e.g., voting, 
million dollar test) 

• Collecting opinions from different user and customer groups about their preferences (e.g. top ten requirements) 

• Analysing requirements from different viewpoints (e.g. Wiegers’ method, Cost -value approach) 

III. Indentations and Equations 
3.1 Data Collection & Analysis 

A) Selection of organization 

> Ten small and medium level enterprises were selected based on convenient sampling. 

> The investment of software companies was lesser than 20 Lakhs 

B) Sampling population 

> As many as 80 samples were included as part of data for the study. The Participants belonged to all the three various 
levels of organization. 

C) Data collection 

> An exhaustive questionnaire was prepared and data was collected with regard to understanding requirements 
prioritization 

D) Stages of Data collection 



Figure 1: Stages of Data Collection followed by Author 


3.2 Hypothesis: 

HI - A positive relationship exists between Product and satisfaction of customer 
H2 - Value of your product is directly proportional to satisfaction level of customer 


Table 1 

Mean and Std. Deviation of few questions 



Mean 

Std.Deviation 

Which of the following words would you use to describe our products 

18 

.86 

How well do our products meet your needs 

19 

.92 

How would you rate the value for money of the product 

20 

.75 

How would you rate the quality of the product? 

17 

.62 

Which of the following words would you use to describe our products 

19 

.56 

How well do our products meet your needs 

20 

1.2 

How would you rate the value for money of the product 

18 

.98 
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Figure 2: Line Graph representing Mean and Std. Deviations 

Table 2 

Respondents opinion for description on products 


Which of the following words would you use to describe our products 

Reliable 

30 

High Quality 

10 

Useful 

10 

Good value for money 

15 

Overpriced 

4 

Impractical 

3 

Ineffective 

1 

Poor Quality 

0 



■Seriesl 


Figure 3: Line Graph representing Quality of Product 
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Table 3 


Respondents opinion for customer satisfaction 


How well do our products meet your needs 

Not at all well 

5 

Extremely well 

30 

Somewhat well 

15 

Very well 

20 

Not so well 

10 



Figure 4: Line Graph representing customer satisfaction Level 


3.3 Analysis & Interpretation 

> The Data collected has been primarily tabulated & Master table was prepared 

> Sample was tested for reliability using Cronbach’s alpha 

> Percentage analysis is the basic tool for analysis 

> Regression analysis a statistical process for estimating the relationships among variables is used 

Cronbach's alpha is a measure of internal consistency, that is, how closely related a set of items are as a group. It is 
considered to be a measure of scale reliability. A "high" value for alpha does not imply that the measure is unidimensional. 
If, in addition to measuring internal consistency, you wish to provide evidence that the scale in question is unidimensional, 
additional analyses can be performed. Exploratory factor analysis is one method of checking dimensionality. Technically 
speaking, Cronbach's alpha is not a statistical test - it is a coefficient of reliability (or consistency). 

Cronbach ’.v value was 0.82 

3.4 Regression Analysis 


Model Summary- 1 


Model 

R 

R Square 

Adjusted R Square 

Std. Error of the Estimate 

1 

.843“ 

.652 

.650 

.747 


Dependent Variable(X): A positive relationship exists between Teaching and students 
Independent Variable(Y): How well do professors teach in college 

In Model Summary 1 - 0.84 means that 84% of the variation of y-values around the mean is explained by the x-values. In 
other words, 84% of the values fit the model. 
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HO - No relationship exists between Product and satisfaction of customer 
HI - A positive relationship exists between Product and satisfaction of customer 


Model Summary - 2 


Model 

R 

R Square 

Adjusted R Square 

Std. Error of the Estimate 

2 

.710“ 

.757 

.755 

.725 


Dependent Variable(X): Innovative methods will help in enhancing results 
Independent Variable(Y): How helpful is your mentor 

In Model Summary 2 - 0.71 means that 71% of the variation of y-values around the mean is explained by the x-values. In 
other words, 71% of the values fit the model. 

HO - Value of your product is not related to satisfaction level of customer 

H2- Value of your product is directly proportional to satisfaction level of customer 

Alternate Hypothesis is accepted. 


IV. Conclusion 

A positive relationship exists between Product and satisfaction of customer & Value of your product is directly proportional 
to satisfaction level of customer are accepted by the pilot survey conducted For researchers, this study shall provide a broad 
analysis of the practical challenges and characteristics of requirements prioritization and long-term planning in market-driven 
software development. Our results indicate that requirements prioritization in practice is a broader issue than just comparing 
a set of requirements at the same level of abstraction with each other, as is assumed in many existing prioritization methods. 
Our results shall provide implications to researchers about what should be taken into account when developing methods and 
practices for requirements prioritization and long-term planning. For example, the researchers in the field might benefit from 
understanding that the three main aspects (business, customer& users, and implementation) are used in practice in 
requirements prioritization. 
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